Systems and methods for context-based event detection and determination

ABSTRACT

The disclosed embodiments include methods and systems for providing context-based event determination and/or context-based event triggered financial product offerings. Scenario modeling data is maintained for a plurality of personal event scenarios. Personal event data representing a personal spike for a user of a client device is received from one or more computer systems over a network where the personal spike comprises an instance of personal event data that deviates from a baseline of personal event data determined for the user. Contextual data related to the personal event data is collected from one or more computers. Using the scenario modeling data, contextual data and the personal event data identifying the at least one personal spike, likely personal event scenarios consistent with the contextual data are identified. Methods and systems to establish a personal baseline from instances of personal event data are also described.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit under 35 U.S.C. §119(e) of U.S.Provisional Application Ser. No. 62/248,900 filed Oct. 30, 2015, thecontent of which is incorporated by reference herein in its entirety.This application further claims the benefit under 35 U.S.C. §119(e) ofU.S. Provisional Application Ser. No. 62/248,881 filed Oct. 30, 2015,the content of which is incorporated by reference herein in itsentirety.

TECHNICAL FIELD

The disclosed embodiments generally relate to systems, methods, andapparatuses for context-based event detection and determination, and forexample, and without limitation, to systems and methods for providingcontext-based event triggered product and/or service offerings based onmonitored sensor data obtained from network devices.

BACKGROUND

Many people are living pay cheque to pay cheque. Being able to meetfinancial obligations in both times of anticipated and unanticipatedevents, where additional financing may be required, becomes an extraburden and stress. This stress may be compounded by the stress andanxiety and other activities of dealing with the unexpected eventitself. Without immediate access to an emergency fund, such as savings,liquid investments, a line-of-credit or other financing, most peoplestruggle with the steps involved in coming up with the money needed toget through this transitional time. Even if financing is ultimatelyobtained, applicants still have to go through the steps of shopping,applying and qualifying for it. And whether they are living pay chequeto pay cheque or not, the notion of taking on debt can be stressful.Someone might wonder: how much money will I need to support me throughthis; how will I get the money; how will I pay it back; and where do Istart? Having a way to anticipate people's cash flow needs and to offerthem a solution that eliminates these questions before they may be evenconsidered, is a valuable offering in today's busy world. This is truein times of unanticipated events, where events happen outside ofsomeone's control, as well as anticipated events, where one's preferenceis to focus on other details. Being able to provide cash, when itsneeded most, might simply be a way to delight and surprise a person, andincrease customer loyalty.

SUMMARY

The disclosed embodiments include systems and methods to providecontext-based event detection and determination and context-based eventtriggered product and/or service offerings. As used herein, “A and/or B”is an “inclusive or” expression and means “one of A or B or both A andB”. For example, “a product and/or service” means “a product or aservice or both a product and a service.”

The disclosed embodiments include methods and systems for providingcontext-based event determination and/or context-based event triggeredfinancial product offerings. Scenario modeling data is maintained for aplurality of personal event scenarios. Personal event data representinga personal spike for a user of a client device is received from one ormore computer systems over a network where the personal spike comprisesan instance of personal event data that deviates from a baseline ofpersonal event data determined for the user. Contextual data related tothe personal event data is collected from one or more computers. Usingthe scenario modeling data, contextual data and the personal event dataidentifying the at least one personal spike, likely personal eventscenarios consistent with the contextual data are identified. Methodsand systems to establish a personal baseline from instances of personalevent data are also described.

There is disclosed in one aspect, a system, comprising: a storagedevice; and at least one processor coupled to the storage device, thestorage device storing software instructions for controlling the atleast one processor when executed by the at least one processor, the atleast one processor being operative with the software instructions andbeing configured to: maintain scenario modeling data related to aplurality of personal event scenarios; perform operations to communicatewith one or more computer systems over a network to receive personalevent data representing a personal spike for a user of a client device,the personal spike comprising an instance of personal event data thatdeviates from a baseline of personal event data determined for the user;perform operations to communicate with one or more computer systems overthe network to collect contextual data related to the personal eventdata; and, using the scenario modeling data, contextual data and thepersonal event data identifying the at least one personal spike:determine and provide likely personal event scenarios consistent withthe contextual data.

The personal spike may deviate at least a threshold amount from thebaseline of personal event data. The contextual data may comprise one ormore of: emotion characterization data; personal spike time ofoccurrence data; user browsing history data; user calendar data; usermessaging data comprising email, text, voice, and/or social media datafor communications sent or received by the user; user positional datacomprising location based services data, trafficlinfrastructure data,utility service data comprising 911/emergency services dispatch data,Internet of Things (IoT) data; proximity social trend/feed datacomprising social media data originated by friends/family or otherperson sharing a proximity relationship to the user; associatedtransaction behaviour data; and general information comprising news,weather, sports, business and artslentertainment information.

The at least one processor may be further configured to select fromamong the contextual data collected using at least one relationship. Therelationship may be a time relationship associated with a time ofoccurrence for the personal spike. Each of the personal event scenariosmay be associated with a respective time window associated with a timeof occurrence of the personal spike and the step of using for aparticular personal event scenario may be responsive to the time windowto determine which contextual data to evaluate for the particularpersonal event scenario. The personal event scenarios may be grouped bylike time windows and evaluated in order beginning with the shortesttime window.

The at least one processor may be further configured to, for each of thelikely personal event scenarios, determine a likelihood that arespective likely personal event scenario is correctly predicted. The atleast one processor may be further configured to provide the likelypersonal event scenarios in association with the likelihood.

The at least one processor may be further configured to: performoperations to communicate with the one or more computer systems over thenetwork to receive feedback in respect of the occurrence of the likelypersonal event scenario; and use the feedback to maintain the scenariomodeling data.

In one aspect there is disclosed a computer implemented methodcomprising: maintaining, by at least one processor, scenario modelingdata related to a plurality of personal event scenarios; performing, byat least one processor, operations to communicate with one or morecomputer systems over the network to receive personal event datarepresenting a personal spike for a user of a client device, thepersonal spike comprising an instance of personal event data thatdeviates from a baseline of personal event data determined for the user;performing, by at least one processor, operations to communicate withone or more computer systems over the network to collect contextual datarelated to the personal event data; and, using, by at least oneprocessor, the scenario modeling data, contextual data and the personalevent data identifying the at least one personal spike: determining andproviding likely personal event scenarios consistent with the contextualdata.

There is disclosed in one aspect a system comprising: a storage device;and at least one processor coupled to the storage device, the storagedevice storing software instructions for controlling the at least oneprocessor when executed by the at least one processor. The at least oneprocessor is operative with the software instructions and configured to:perform operations to communicate with one or more first devices over anetwork to receive instances of personal event data for a user of aclient device; perform operations to communicate with one or more seconddevices over a network to receive contextual data for the user;establish and maintain a baseline of personal event data for the userusing the contextual data and instances of personal event data; andidentify a personal spike experienced from one or more instances ofpersonal event data that deviate from the baseline.

At least some of the first devices and some of the second devices may bethe same devices.

The at least one processor may be further configured to performoperations to communicate to the personal spike to a personal eventscenario determination computer system.

The contextual data may comprise: emotion characterization data;personal spike time of occurrence data; user browsing history data; usercalendar data; user messaging data comprising email, text, voice, and/orsocial media data for communications sent or received by the user; userpositional data comprising location based services data,traffic/infrastructure data, utility service data comprising911/emergency services dispatch data, Internet of Things (IoT) data;proximity social trend/feed data comprising social media data originatedby friends/family or other person sharing a proximity relationship tothe user; associated transaction behaviour data; and general informationcomprising news, weather, sports, business and arts/entertainmentinformation.

Instances of personal event data may comprise data received via inputdevices of the one or more first devices including at least some of: akeyboard, a touch screen, a camera, a microphone and biometric or othersensors comprising a heart rate monitor, an EEG/EKG monitor, a vitalsign sensor and a heat detector.

To identify a personal spike the at least one further processor may beconfigured to further use contextual data associated with respectiveinstances of personal event data. The contextual data may comprise atleast one of time of occurrence data and location data.

The at least one processor may be further configured to: performoperations to communicate with the one or more computer systems over thenetwork to receive feedback in respect of the occurrence of the personalspike; and use the feedback to maintain the baseline.

There is disclosed in one aspect, a computer-implemented method. Themethod comprises: performing, by at least one processor, operations tocommunicate with one or more first devices over a network to receiveinstances of personal event data for a user of a client device;performing, by at least one processor, operations to communicate withone or more second devices over a network to receive contextual data forthe user; establishing, by at least one processor, and maintain abaseline of personal event data for the user using the contextual dataand instances of personal event data; and identifying, by at least oneprocessor, a personal spike experienced from one or more instances ofpersonal event data that deviate from the baseline.

The disclosed embodiments further include a storage device and at leastone processor coupled to the storage device. The storage device maystore software instructions for controlling the at least one processorwhen executed by the at least one processor, for example, to perform themethod or methods as herein described.

Additional objects and advantages of the disclosed embodiments will beset forth in part in the description that follows, and in part will beobvious from the description, or may be learned by practice of thedisclosed embodiments. The objects and advantages of the disclosedembodiments will be realized and attained by means of the elements andcombinations particularly pointed out in the appended claims.

It is to be understood that both the foregoing general description andthe following detailed description are exemplary and explanatory onlyand are not restrictive of the disclosed embodiments as claimed.

The accompanying drawings constitute a part of this specification. Thedrawings illustrate several embodiments of the present disclosure and,together with the description, serve to explain the principles of thedisclosed embodiments as set forth in the accompanying claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts an exemplary computing environment consistent withdisclosed embodiments.

FIG. 2 depicts an exemplary computing system consistent with thedisclosed embodiments.

FIG. 3 depicts a flowchart for an exemplary personal event sensingprocess consistent with the disclosed embodiments.

FIGS. 4A-4B depict flowchart for an exemplary context-based eventdetection process consistent with the disclosed embodiments.

FIG. 5 depicts a flowchart for an exemplary context-based eventdetermination process consistent with the disclosed embodiments.

FIG. 6 depicts a flowchart for an exemplary context-based eventfinancial product offering process consistent with the disclosedembodiments.

DESCRIPTION OF THE EMBODIMENTS

Reference will now be made in detail to embodiments of the presentdisclosure, examples of which are illustrated in the accompanyingdrawings. Wherever possible, the same reference numbers will be usedthroughout the drawings to refer to the same or like parts.

As the H. W. Longfellow maxim says, “Into each life some rain mustfall”. Events, whether unfortunate, tragic, joyous, fortuitous,anticipated, or unanticipated, often entail financial obligations orhave financial implications for those associated with the event. Aperson experiencing a significant event often experiences associatedchanges to the person's personal baseline, particularly upon or shortlyafter the initial occurrence of the event—a personal spike may beoccasioned. Physiological and other data related to a person may bemonitored to establish a baseline and spikes detected to assist with thedetermination of the occurrence of a significant personal event.

Analyzing associated contextual data may determine the nature of thepersonal event and the person's relationship to it. For example, was thepersonal event a car accident where the person was driver? Was thepersonal event a wedding engagement where the person was expected tocarry a significant burden of paying for the wedding? These and manyother personal event scenarios may be modeled and programmed to assistwith the analysis and determination. Financial obligations or otherfinancial impacts may be associated to respective scenarios as may benon-financial obligations or impacts. Actions such as the offering ofspecific products and/or services or withdrawal of products and/orservices may be associated. Receptivity indicators may also beassociated to respective scenarios (e.g. by the events data), forexample, providing an indication of whether or when to make or withholdfrom making offerings of products. Feedback and other learningtechniques may be employed to refine the detection of personal events,the determination of applicable personal event scenarios and relations,associated obligations, impacts and actions as well as receptivityindicators to offerings, etc.

The average couple takes 14 months to plan their wedding and spendsroughly $30,000 in wedding costs. During this time, those paying for theultimate event, whether the couple or parents/family, etc., have to makemany financial commitments, which could be a source of stress anddisagreement. Being able to identify the need and provide for theadditional cash flow could assist.

A car accident may significantly influence a person's automobileinsurance rates and the person's monthly living expenses. A person maydecide to fix damages outside of an insurance policy to mitigate theincrease in on-going payments or where coverage is lacking,necessitating access to immediate cash.

These examples are some of the many applications where the disclosedembodiments may be implemented. Other aspects, features, andfunctionalities of the disclosed embodiments are described below.

FIG. 1 depicts an exemplary computing environment 100 consistent withthe disclosed embodiments. In one aspect, computing environment 100 mayinclude one or more context-based event detection systems (e.g., 132),which may be associated with one or more context-based event detectionentities (e.g., 130). In additional aspects, environment 100 may includeone or more client devices (e.g., 102), which may be associated withrespective one or more users (e.g., 110). Environment 100 may alsoinclude one or more context-based event determination systems (e.g.,152), which may be associated with one or more context-based eventdetermination entities (e.g., 150). In further aspects, environment 100may include one or more financial offering systems (e.g., 172), whichmay be associated with one or more financial offering entities (e.g.170). Though described as financial offering systems and entities, suchmay be non-financial offering systems and entities or a single systemand entity may provide both financial and non-financial offerings.Environment 100 may include both financial offering systems as shown andnon-financial offering systems as not shown.

In some embodiments, environment 100 may include communication network120. In some aspects, communication network 120 may represent any typeof network or medium of digital communication for transmittinginformation between computing devices. For example, communicationnetwork 120 may include a LAN, a wireless LAN, a cellular network, a GSMnetwork, a satellite network, an RF network, a Near Field Communication(NFC) network (e.g., a WiFi network), a wireless Metropolitan AreaNetwork (MAN) connecting multiple wireless LANs, NFC communicationlink(s), any physical wired connection (e.g., via an I/O port), and aWAN (e.g., the Internet). In some embodiments, communication network 120may be secured through physical encryption (e.g., line encryption), byrequiring information to be encrypted on other computer systems (e.g.,end encryption), and the like.

In certain aspects, communication network 120 may include any accessiblenetwork or networks interconnected via one or more communicationprotocols, including hypertext transfer protocol (HTTP) and transmissioncontrol protocol/internet protocol (TCP/IP). Communications protocolsconsistent with the disclosed embodiments also include protocolsfacilitating data transfer using radio frequency identification (RFID)communications and/or NFC. In some aspects, communication network 120may also include one or more mobile device networks, such as a GSMnetwork or a PCS network, allowing devices (e.g., client device 112, atriggering device, etc.) to send and receive data via applicablecommunications protocols, including those described herein.

In certain aspects, context-based event detection system 132 ofenvironment 100 may be configured to process, store, receive, obtain,and transmit information. In certain aspects, such systems may beconfigured to execute software instructions to perform one or moreprocesses consistent with the disclosed embodiments. In someembodiments, context-based event detection entity 130 may include anyentity storing, using, managing, or processing information related toproviding context-based detection for a user or other entity. Forexample, in some aspects, a context-based event detection entity mayinclude a business entity providing such detection as a service.

In certain aspects, context-based event detection system 132 may includeone or more servers (e.g., server 134), and one or more data storages(e.g., database 136). In some embodiments, server 134 may includesoftware programs and one or more processors for executing the programs.Server 134 may be configured to execute software instructions to performone or more processes consistent with the disclosed embodiments. In oneembodiment, for example, a user device (e.g., 102) and/or anothercomputing system may exchange information facilitating execution of theone or more processes consistent with the disclosed embodiments. Thesoftware instructions of server 134 may be incorporated into a singlecomputer, a single server, or any additional or alternative computingdevice apparent to one of ordinary skill in the art. Server 134 may alsoinclude distributed computing devices and computing systems, and mayexecute software instructions on separate computing systems and servers.Context-based event detection system 132 may include one or more datarepositories (e.g. database 136) configured to store informationconsistent with the disclosed embodiments (e.g., information related to,obtained from, and/or sent to client devices or context-based eventdetermination system 152, user preferences received over communicationnetwork 120, etc.). The information may comprise personal event data 138and client data 140, for example. Client data 140 may compriseinformation identifying a particular user and/or associated clientdevices of the particular user from which personal event data 138 isreceived. Personal event data 138 may comprise the personal event datareceived and/or processed by system 132 associated with the user via theclient data, for example. For each user, the personal event data maydefine a personal baseline with which to compare to new instances ofpersonal event data, for example, to identify a personal spike orinstance of such data that may represent a significant personal event.As described below, personal event data 138 may include instances ofcontextual data 142.

In some aspects, context-based event detection system 132 may include acomputer having one or more processors selectively activated orreconfigured by a computer program. Such a computer may be configured asa particular computing system based on execution of softwareinstructions that perform one or more processes consistent with thedisclosed embodiments. In certain aspects, context-based event detectionsystem 132 may be incorporated as corresponding nodes in a distributednetwork, and/or as corresponding networked servers in a cloud-computingenvironment. In one embodiment, context-based event detection system 132may communicate with one or more additional servers that facilitate thedistribution of processes for parallel execution by the additionalservers.

In some embodiments, environment 100 may include one or more clientdevices (e.g., client device 102) and/or other scenario data collectingdevices (not shown). In certain embodiments, a client device and/orpersonal data collection device may include any computing, datatransmitting, data receiving, or data processing device consistent withthe disclosed embodiments. In some aspects, a personal data collectingdevice may include a client device; however, a client device may not bea personal data collecting device.

In certain aspects, a client device or personal data collection devicemay include any device capable of providing and receiving informationover a communication network (e.g., communication network 120). Forexample, a client device or personal data collection device may includea personal computer, a laptop computer, a tablet computer, a notebookcomputer, a hand-held computer, a personal digital assistant, a portablenavigation device, a mobile phone, a wearable device (e.g., a smartwatch), an embedded device, a smartphone, an RFID device, a pager, andany additional or alternate device capable of receiving or providinginformation to communications network 120 (e.g., a computer system 200of FIG. 2).

Additionally or alternatively, client and personal data collectiondevices consistent with the disclosed embodiments may include apositioning device or sensor (e.g., global positioning system (GPS)unit, an RFID unit, etc.) capable of obtaining positioning dataindicative of a current geographic position of the corresponding clientand/or scenario data collection device. In certain aspects, the clientand/or personal data collection devices may process the receivedpositional data and transmit portions of the received positioning datato system 132. This transmitted data may be transmitted in associationwith personal event data collected by such devices, for example, atregular or predetermined intervals, in response to requests receivedfrom system 130 or otherwise (e.g. when personal event data collectedexceeds a certain threshold as determined by the device).

As described below, context-based event detection system 132 may processthe received positional data to monitor current geographic positions ofthe client and/or personal data collection devices to gather contextualdata (e.g. 142) with which to determine the context associated with thepersonal spike and to determine a personal event scenario associatedwith the personal spike. Other contextual data may be collected byclient and/or personal data collection devices and transmitted tocontext-based event detection system 132. Contextual data 142 mayinclude user data such as a user's contact data, calendar data,messaging or other communication related data, time, date, location,among many other context data. Other contextual data is discussedfurther below in relation to context-based event determination entity150 as contextual data 160.

Additionally or alternatively, client and personal data collectiondevices consistent with the disclosed embodiments may include one ormore I/O interfaces and I/O devices and or be coupled via communicationinterface 224 with such I/O devices. I/O devices for receiving clientinput include but are not limited to a keyboard, touch screen, camera,microphone, biometric or other sensors such a heart rate monitors,EEG/EKG monitors, vital sign sensors, heat detectors, etc. Client device102 may receive input actively such as when a user is intentionallyusing an I/O device to operate the client device 102 or passively suchas via a biometric sensor monitoring a biometric function of the user ina background manner. Client device 102 may be configured to receiveinput and process such input to generate instances of personal eventdata. Such personal event data may be relative to separate specificinput types (e.g. individual voice, keyboard or sensor input types) ormay be processed as a measure of a combination of one or more suchinputs (e.g. audio (e.g. voice) and visual data from a microphone andcamera or audio and biometric sensor in combination, etc.).

Personal event data, gathered from instances over time, may be useful todefine a personal baseline for the user such as may be generated andmaintained by context-based event detection system 132. Respectiveinstances of personal event data may be associated with a time ofoccurrence. Respective instances of personal event data (e.g. clientevent data 106) may be communicated to context-based event detectionsystem 132 such as periodically at regular or irregular intervals.Instances of personal event data (including contextual data) may beaggregated by client device 102, stored as client event data 106 andcommunicated in a batch or other aggregation.

Models of such data (e.g. personal event data and contextual data) maybe defined for a specific user to define a personal baseline. A personalbaseline (e.g. a model) for the user may take many forms. Variousmachine learning and/or prediction techniques may be employed incomponents of the system such as structured prediction, probabilisticgraphic models, Markov models including Hidden Markov Models (HMM),Bayesian networks, random fields, Neural Nets, Support Vector Machines(SVM), etc. The personal baseline model may be used to identify personalspikes where instances of the personal event data deviate from thepersonal baseline. Contextual data may also be evaluated whendetermining the occurrence of a personal spike. Deviation may exceed athreshold may be determined when one or more instances of personal eventdata exceed a threshold. By way of one example, instances of heart ratedata maybe collected as well as instances of calendar data showing auser's physical workout schedule. Such personal event data andcontextual data may be provided to the model to define the personalbaseline. Future instances of personal event data, including time ofoccurrence and/or location data, may be evaluated using the model.Should a high heart rate be detected during a physical work out or at alocation of such a workout, as modeled by the baseline, such personalevent data may be ignored as not representing a personal spike. A highor abnormally low heart rate at a different location, such as on ahighway, may indicate a personal spike. The spike may indicate apersonal event scenario such as a car accident.

Client device 102 may apply a threshold to instances of personal eventdata to determine when to communicate such data. For example,context-based event detection system 132 may determine a personalbaseline and one or more thresholds. The thresholds may be communicatedto client device 102. Such thresholds may be used to evaluate andtrigger communication of instances of personal event data to system 132.

In some embodiments, a client device may be associated with one or moreusers (e.g., user 110). In one example, a user may use client device toperform one or more processes consistent with the disclosed embodiments.For example, user 110 may use client device 102 to input information andto exchange information with other systems in environment 100, such assystem 172 or another computing system (not shown) in connection withcommunications network 120.

In certain aspects, context-based event determination system 152 ofenvironment 100 may be configured to process, store, receive, obtain,and transmit information over communications network 120 for use inprocesses consistent with the disclosed embodiments. In certain aspects,such systems may be configured to execute software instructions toperform one or more processes consistent with the disclosed embodiments.In some aspects, context-based event determination system 152 may beassociated with one or more context-based event determination entities(e.g., entity 150). In some embodiments, context-based eventdetermination entity 150 may include any entity storing, using,managing, or processing information related to providing context-basedevent determination for a user or other entity (e.g., any of theentities described in connection with context-based event detectionentity 130, financial offering entity 170, a separate business entity, ahuman user, etc.). For example, in some aspects, a context-based eventdetermination entity may include a business entity providing suchdetermination as a service. In some embodiments, context-based eventdetermination entity may be related to, concomitant with, or associatedwith context-based event detection entity 140 or financial offeringentity 170, although such relationship is not required.

In some aspects, context-based event determination system 152 mayinclude a computer having one or more processors selectively activatedor reconfigured by a computer program. Such a computer may be configuredas a particular computing system based on execution of softwareinstructions that perform one or more processes consistent with thedisclosed embodiments. In certain aspects, personal event determinationsystem 152 may be incorporated as corresponding nodes in a distributednetwork, and/or as corresponding networked servers in a cloud-computingenvironment. In one embodiment, context-based event determination system152 may communicate with one or more additional servers that facilitatethe distribution of processes for parallel execution by the additionalservers.

As noted, in certain aspects, context-based event determination system152 may include one or more servers (e.g., server 154), and one or moredata storages (e.g., database 156). In some embodiments, server 154 mayinclude software programs and one or more processors for executing theprograms. Server 154 may be configured to execute software instructionsto perform one or more processes consistent with the disclosedembodiments. In one embodiment, for example, a context-based eventdetermination system (e.g., 152) and/or another computing system mayexchange information facilitating execution of the one or more processesconsistent with the disclosed embodiments. The software instructions ofserver 154 may be incorporated into a single computer, a single server,or any additional or alternative computing device apparent to one ofordinary skill in the art. Server 154 may also include distributedcomputing devices and computing systems, and may execute softwareinstructions on separate computing systems and servers. The one or moredata repositories (e.g. database 156) may be configured to storeinformation consistent with the disclosed embodiments (e.g., informationrelated to, obtained from, and/or sent to user device 102, context-basedevent detection system 132, financial offering system 172, userpreferences received over communication network 120, etc.). Theinformation may comprise client data 158, contextual data 160, andscenario modeling data 162, for example. Client data 158 may compriseinformation identifying a particular user and/or associated clientdevices of the particular user from which personal data for particularpersonal events is generated. Such data may also identify friends and/orfamily of the particular user and respective client devices thereof fromwhich respective personal data is collected.

Contextual data 160 may comprise information associated with thepersonal spike. Such information may include but is not limited to anyone or more of:

-   -   emotion characterization data (e.g. client data collection        devices/systems may be calibrated to determine a level of        anxiety and whether such anxiety represents a positive or        negative client response—e.g. a strong positive emotion can be        correlated with overwhelming joy. Calibration may include a        learning process to determine personal states, for example,        using a large training set);    -   personal spike time of occurrence data;    -   user browsing history data;    -   user calendar data;    -   user messaging data (e.g. email, text, voice, social media data        related to communications sent or received by the user);    -   user positional data, location based services data,        traffic/infrastructure data, utility service data (e.g. 911        dispatch data), Internet of Things (IoT) data. IoT data        typically provides very targeted contextual data which is        specific to individual items/things such as: vehicle telemetry        data when connected to a vehicle, home/office or other location        data such as fire detection when connected to a sensor/alarm,        etc.;    -   proximity social trend/feed data such as social media data        originated by friends/family or other person sharing a proximity        relationship to the user (e.g. co-worker, person sharing an        experience such as a co-traveler on a tour etc.). Such data may        be generated before or following a detected personal spike; and    -   associated transactional data such as specific financial        transactions made in correlation to a personal event.        Transactional information can be collected to understand the        correlation between events and specific transactional        behaviours. As an example, every time a specific person goes        through a relationship break up, he or she goes to a casino and        spends an excessive amount of money. Such a correlation may        assist to anticipate a cash flow need, in advance to the casino        event, the next time this person goes through a break up.        Similarly, by way of another example, a person may have achieved        a major goal they have been working towards (e.g. achieved a        professional designation or promotion, closed a major        transaction, finished a fitness or sporting goal, etc.) and        thereafter spends a large sum of money on a big ticket purchase        as a reward (e.g. electronics, restaurant, clothes, etc.).

Contextual data may also include general information, whether or notrelated specifically to user 110 or the user's friends and family suchas news, weather, sports, business, arts/entertainment information.Contextual data 160 may be received from user device 102, other userdevices (not shown), context-based event detection system 132, and/orother systems (not shown), which may be operated or provided by thirdparty entities (not shown).

Contextual data 160 may be obtained and maintained by context-basedevent determination system 152 periodically or triggered upon theoccurrence of a personal spike. Specific instances of contextual data160 may be related to one another such as by time of occurrence and/orrelationship to client device 102 and/or user 110 or friends and familythereof, among other relationships. Time windowing, such as by definingvarious time spans, may be used to relate various contextual data. Forexample, a data set of contextual data may be defined for use todetermine a personal event scenario by selecting contextual data for theuser that is within time spans before and/or after the time ofoccurrence of a personal spike. Contextual data may be related usingmore than one personal spike for the user and/or connected circle offriends and family.

Scenario modeling data 162 includes data that models various personalevent scenarios and, using at least the contextual data and may includeusing personal event data and/or client data, is useful to determine oneor more likely personal event scenarios associated to the personal spikethat is consistent with the contextual data. Personal event scenariosmay include but are not limited to: an accident, a loss of job, a lossof a family member, a damage to a home, an expectation of a new child,an engagement/wedding announcement, an acceptance to college, a purchaseor move to a new home, a new business opportunity, etc. Scenarios mayalso include further particularity and/or a relationship of theuser/client to the event. For example, an accident may be particularizedas a car accident. The relationship may be that the user was directlyinvolved in the car accident, was a witness to the car accident or is afriend or family member of another involved in a car accident.Operations of the systems and methods performed thereby may beconfigured with scenario modeling data and to examine the detected datato locate scenarios that are personal to the user and/or friend orfamily and which are likely to affect the user's and/or friend's orfamily's financial situation such that an offer of a financial productmight assist. The model may have other scenarios (e.g. where offers of afinancial product to the user are not indicated) to assist todisambiguate among candidate scenarios when a spike or spikes areexamined.

As described further below, some personal scenarios may be associatedwith potential financial obligations and impacts and associatedfinancial actions such as offerings of financial products/services (orwithdrawals of financial products/services) that may assist with thescenario. Some scenarios may be associated with other non-financialofferings of assistance and still others with no offerings. Receptivityindicators may also be associated to the scenarios. For example theindication may relate to a specific financial offering, suggesting atiming when to make or delay making an offer or not making such anoffer. The occurrence of a personal event and an associated receptivityindicator may be useful to configure a variety of communications betweena financial institution and its clients. Such data may be useful to callcentre operators, call list compilers such as when populating clientlists, mailing campaign (whether electronic or otherwise) listcompilers, etc. Receptivity may be useful to populate a client list ororder a client list such as to bump a person up, down or off such lists.

As described further below, receptivity indicators may be developedthrough a learning mechanism, for example, analyzing response rates tooffers made after certain personal events are detected, and feed backinto a financial event model. Alternatively or in addition,surveys/questionnaires may be conducted in regard to client servicefollowing such offers to elicit feedback about appropriateness, etc.Receptivity may be measured or gauged in an aggregate basis acrossmultiple customers/offer recipients and/or on an individualcustomer/recipient basis. A receptivity measure may indicate howreceptive an individual is likely to be to certain types ofoffers/messages, which may be associated to a time of offer after thecommencement of the personal scenario (detection of the personal spike).

Scenario modeling data 162 and processes to determine likely personalevent scenarios may take many forms. Various machine learning and/orprediction techniques may be employed in components of the system suchas structured prediction, probabilistic graphic models, Markov modelsincluding Hidden Markov Models (HMM), Bayesian networks, random fields,Neural Nets, Support Vector Machines (SVM), etc. Preferably, suchscenario modeling data 162 and processes when executed with contextualdata associated with one or more personal spikes may provide anindication of a likelihood that a candidate scenario is a correct one,(e.g. using a confidence interval), which may be useful to select amongthe candidates.

Personal modeling data may be defined by training a machine leaming datamodel with example contextual data thereby to define various aspects ofthe model for use when processing actual contextual data associated witha real user's personal spike. Such personal modeling data may be refinedand maintained to hone the quality and other aspects of the model, forexample, to achieve more accurate output.

In accordance with an embodiment, processing to determine a personalevent scenario may be undertaken one or more times for a particularpersonal spike. For example, using the time windowing approach mentionedabove, more and/or different contextual data may be selected and appliedto or processed by the scenario modeling data to output candidatepersonal event scenarios. For example, examining the contextual data 160within 2 hours of an occurrence of a personal spike may output acandidate event scenario with a 45% confidence interval. Examining thecontextual data 160 within 48 hours of an occurrence of a personalspike, where more or different contextual data is available, may outputthe candidate event scenario with an 80% confidence interval. Similarly,time windowing may be used to look back, to data collected before thetime of occurrence of the personal spike, using different time intervalsto produce candidate personal event scenarios and associated confidenceintervals.

Examining the contextual data 160 may output one or more candidatepersonal event scenarios with associated representation of likelihood orconfidence that the model is accurately determining the personal event.A threshold may be established and used to select among such candidates.

As noted above, the candidate scenarios may include a relationshipfactor relating the user and the personal event determined by system152. For example, relationship may be that the user is directly involvedor is involved indirectly such as through a friend or family member. Thedetermination may identify the friend or family member who directlyexperienced a personal event. Such information identifying the friend orfamily member may be used to trigger an offering of a financial productto the friend or family member and/or to the user on behalf of thefriend or family member. Such information identifying the friend orfamily member may be useful as contextual information, etc. whenprocessing a personal spike or spikes and contextual information of thefriend or family member.

In certain aspects, financial offering system 172 of environment 100 maybe configured to process, store, receive, obtain, and transmitinformation over communications network 120 for use in processesconsistent with the disclosed embodiments. In certain aspects, suchsystems may be configured to execute software instructions to performone or more processes consistent with the disclosed embodiments. In someaspects, financial offering system 172 may be associated with one ormore financial offering entities (e.g., entity 170). In someembodiments, financial offering entity 150 may include any entitystoring, using, managing, or processing information related to providingfinancial offerings, such as a financial institution, for a user orother entity (e.g., any of the entities described in connection withcontext-based event detection entity 130, context-based eventdetermination entity 150, a separate business entity, a human user,etc.). For example, in some aspects, a financial offering entity mayinclude a business entity providing such financial offering as aservice. In some embodiments, financial offering entity may be relatedto, concomitant with, or associated with context-based event detectionentity 140 or context-based event determination entity 150, althoughsuch relationship is not required.

In some aspects, financial offering system 172 may include a computerhaving one or more processors selectively activated or reconfigured by acomputer program. Such a computer may be configured as a particularcomputing system based on execution of software instructions thatperform one or more processes consistent with the disclosed embodiments.In certain aspects, financial offering system 172 may be incorporated ascorresponding nodes in a distributed network, and/or as correspondingnetworked servers in a cloud-computing environment. In one embodiment,financial offering system 172 may communicate with one or moreadditional servers that facilitate the distribution of processes forparallel execution by the additional servers.

As noted, in certain aspects, financial offering system 172 may includeone or more servers (e.g., server 174), and one or more data storages(e.g., database 156). In some embodiments, server 174 may includesoftware programs and one or more processors for executing the programs.Server 174 may be configured to execute software instructions to performone or more processes consistent with the disclosed embodiments. In oneembodiment, for example, financial offering system 172 and/or anothercomputing system may exchange information facilitating execution of theone or more processes consistent with the disclosed embodiments. Thesoftware instructions of server 174 may be incorporated into a singlecomputer, a single server, or any additional or alternative computingdevice apparent to one of ordinary skill in the art. Server 174 may alsoinclude distributed computing devices and computing systems, and mayexecute software instructions on separate computing systems and servers.The one or more data repositories (e.g. database 176) may be configuredto store information consistent with the disclosed embodiments (e.g.,information related to, obtained from, and/or sent to user device 102,context-based event detection system 132, context-based eventdetermination system 152, user preferences received over communicationnetwork 120, etc.). The information may comprise events data (e.g.financial events data 178), client data (e.g. client financial data180), and products and/or services data (e.g. financial products data182), for example. Unless the context indicates otherwise, financialproducts herein includes financial services. Financial events data 178may include financial offering data associated with particular personalevent scenarios. Financial events data 178 may comprise mapping data toassociate a personal event scenario to one or more particular financialproducts of financial products data 182. Generally then, events data maycomprise mapping data to associate a personal event scenario to one ormore products and/or services of products and/or services data which maybe maintained. The financial offering data may identify specificfinancial products to be offered, the data defining such financialproducts stored as financial products data 182. Data and/or instructionsto determine anticipated needs (e.g. anticipated financial needs)associated with the respective personal event scenario may be included.

Financial products data 182 may include rules or other information (e.g.various “know your client” rules, among others) concerning how to offerand obtain client information to conclude an offering for a specificfinancial product (e.g. a car loan, mortgage, line of credit, etc.).Offers may be made such as by communication to a client device, whetherby telephonic means or data transmission means (e.g. email, SMS (text),etc.) or by other media such as print, etc. delivered to a client ormade orally such as in a meeting between a client and advisor. It willbe understood that, in some aspects, an offer may include anadvertisement or offer that is informational in nature and that, inother aspects, an offer may be a formal or contractual offer, theacceptance of which makes a binding contract.

By way of example, in one aspect, an offer may be defined to bedelivered telephonically, in a campaign, such as via a call centercalling client devices of clients utilizing client lists of a particularfinancial institution. The offer may be informational in nature, forexample, advising that fees for a particular financial product arereduced or waived for new clients/applications initiated in the nextperiod of weeks. Events data such as financial events data 178 maycomprise mapping data to associate a personal event scenario to such aninformational offering even though such an offering may not be designedor indicated to address a need arising from such a personal eventscenario. The association between the personal event scenario and theoffering may indicate that the offering should not be made to theparticular client experiencing the personal event scenario, for example,because it may be perceived as insensitive or otherwise becausereceptivity is likely to be low. The call list may be modified to removeor not include the particular client. Conversely, the mapping mayindicate that such an offering is more likely to be received in afavourable manner and as such the call list may be compiled (populated)to include the particular client and/or reordered to have such a clientcalled early and/or more frequently in the campaign.

Products and or services data may include data and/or instructions onhow a client may qualify for a specific product (e.g. a financialproduct), for example, setting out tests or thresholds to measureagainst a particular client's client data including client financialdata. In some aspects, financial offering system 172 may furthermaintain data and/or instructions to actually process or provide suchfinancial products to clients such as data, processes/work flow, etc.However, it will be appreciated that other financial or non-financialsystems, not shown, may perform operations to provide such financialproducts or non-financial products and/or services to a client.

Client financial data 180 may include the personal event scenariodetermined by system 152. Client financial data 180 may include specificclient financial information for particular users, such as user 110.Client financial data 180 may include but not be limited to creditrating data, income data (whether from employment or business sources,etc.), asset data such as bank account data, investment data and otherasset related data (e.g. cars, home or other real property, personalproperty, etc. including value and liquidity information), insurancedata (e.g. property, health, life insurance) and loan or other liabilityrelated data (e.g. mortgages, business loans, personal or other lines ofcredit, credit cards, etc.) Client financial data 170 may compriseinformation identifying a particular user and/or associated clientdevices of the particular user from which personal data for particularpersonal events is generated and/or to which financial offerings offinancial products may be communicated. Client financial data 170 may beexamined to determine whether a particular client has the ability toaddress any financial need arising from the determined personal eventscenario and/or whether the client may qualify for a particularfinancial product that may be offered upon the determination of thepersonal event scenario. For loan offerings for example, financialinstitutions typically examine a client's credit rating, income, assetsand liabilities and determines debt to debt service ratios. Otherqualifying criteria may be used.

In certain embodiments, the various systems (e.g. 132, 152, 172) mayreceive authorization from another computing system (e.g., a computingsystem associated with the user or any of the entities, etc.) before therespective systems are authorized or permitted to collect personal data,determine a personal event and make a financial offering triggered bysuch personal event.

While FIG. 1 depicts environment 100 with a certain number of clientdevices (e.g., client device 102), context-based event detection systems(e.g., 132), communication networks (e.g., 120), context-based eventdetermination systems (e.g., 152), and financial offering systems (e.g.,172), environment 100 may contain any number of such systems consistentwith the disclosed embodiments. For example, environment 100 may includea plurality of client devices and such systems. Environment 100 may alsoinclude additional communication networks, and other networks not shownin FIG. 1 consistent with the disclosed embodiments.

FIG. 2 depicts a block diagram of exemplary computer system 200 withwhich certain aspects consistent with the disclosed embodiments may beimplemented. For example, in some aspects, computer system 200 mayreflect computer systems associated with a client device (e.g., clientdevice 102), system 132, and the like. In some embodiments, computersystem 200 may include one or more processors 202 connected to acommunications backbone 206 such as a bus or external communicationsnetwork (e.g., any medium of digital data communication such as a LAN,MAN, WAN, cellular network, WiFi network, NFC link, Bluetooth, GSMnetwork, PCS network, communication network 120, and any associatedprotocols such as HTTP, TCP/IP, RFID, etc.).

In certain aspects, computer system 200 may include main memory 208.Main memory 208 may comprise random access memory (RAM) representing atangible and non-transitory computer-readable medium storing computerprograms, sets of instructions, code, or data executed with processor202. When executed by processor 202, such instructions, computerprograms, etc., enable processor 202 to perform one or more processes orfunctions consistent with the disclosed embodiments. In some aspects,such instructions may include machine code (e.g., from a compiler)and/or files containing code that processor 202 may execute with aninterpreter.

In some aspects, main memory 208 may also include or connect to asecondary memory 210. Secondary memory 210 may include a disk drive 212(e.g., HDD, SSD), and/or a removable storage drive 214, such as amagnetic tape drive, flash memory, an optical disk drive, CD/DVD drive,or the like. The removable storage drive 214 may read from and/or writeto a removable storage unit 218 in a manner known to the skilledartisan. Removable storage unit 218 may represent a magnetic tape,optical disk, or other storage medium that is read by and written to byremovable storage drive 214. Removable storage unit 218 may represent atangible and non-transitory computer-readable medium having storedtherein computer programs, sets of instructions, code, or data to beexecuted by processor 202.

In other embodiments, secondary memory 210 may include other means forallowing computer programs or other program instructions to be loadedinto d computer system 200. Such means may include, for example, anotherremovable storage unit 218 or an interface 220. An example of such meansmay include a removable memory chip (e.g., EPROM, RAM, ROM, DRAM,EEPROM, flash memory devices, or other volatile or nonvolatile memorydevices) and associated socket, or other removable storage units 218 andinterfaces 220, which allow instructions and data to be transferred fromthe removable storage unit 218 to computer system 200.

Computer system 200 may also include one or more communicationsinterfaces 224. Communications interface 224 may allow software and datato be transferred between computer system 200 and external systems(e.g., in addition to backbone 206). Communications interface 224 mayinclude a modem, a network interface (e.g., an Ethernet card), acommunications port, a PCMCIA slot and card, etc. Communicationsinterface 224 may transfer software and data in the form of signals,which may be electronic, electromagnetic, optical or other signalscapable of being received by communications interface 224. These signalsmay be provided to communications interface 224 via a communicationspath (i.e., channel 228). Channel 228 carries signals and may beimplemented using wire, cable, fiber optics, RF link, and/or othercommunications channels. In one embodiment, the signals comprise datapackets sent to processor 202. Information representing processedpackets may also be sent in the form of signals from processor 202through communications path 228.

In certain aspects, the computer-implemented methods described hereincan be implemented on a single processor of a computer system, such asprocessor 202 of computer system 200. In other embodiments, thesecomputer-implemented methods may be implemented using one or moreprocessors within a single computer system and/or on one or moreprocessors within separate computer systems in communication over anetwork.

In certain embodiments in connection with FIG. 2, the terms “storagedevice” and “storage medium” may refer to particular devices including,but not limited to, main memory 208, secondary memory 210, a hard diskinstalled in hard disk drive 212, and removable storage unit 218.Further, the term “computer-readable medium” may refer to devicesincluding, but not limited to, a hard disk installed in hard disk drive212, any combination of main memory 208 and secondary memory 210, andremovable storage unit 218, which may respectively provide computerprograms and/or sets of instructions to processor 202 of computer system200. Such computer programs and sets of instructions can be storedwithin one or more computer-readable media. In certain aspects, computerprograms and sets of instructions may also be received viacommunications interface 224 and stored on the one or morecomputer-readable media.

Not shown in FIG. 2 are I/O interfaces or I/O devices, which may becoupled to computer system 200. I/O devices may include keyboards,microphones, speakers, pointing devices, display screens, with ourwithout touch input capabilities, biometric and other sensors to monitoruser functions, position sensors (e.g. for general location, such as aGPS, and/or for relative position/orientation of the device locally suchas using accelerometers and/or gyroscopes), etc.

The disclosed embodiments include systems, methods, andcomputer-readable mediums for storing instructions that, when executedby a processor(s), perform operations for offering financial products toa user. The offerings are triggered on the occurrence of specificpersonal events. In some aspects, the disclosed embodiments may monitorone or more devices relevant to the user and detect a personal “spike”:an occurrence of personal event data that exceeds a threshold for theuser, for example, when compared with the user's personal baseline. Incertain aspects, the disclosed embodiments may determine, usingcontextual data, personal event scenarios associated with the personalspike, and provide a financial offering of a financial product to theuser to assist with the personal event.

For example, FIG. 3 depicts a flowchart for an exemplary personal datacollection process 300 consistent with the disclosed embodiments. Insome aspects, client device 102 system 142 is configured to receiveclient input, whether actively or passively generated by user 110 (step302). At step 304, an instance of personal event data is generated fromthe input, such as for determining or maintaining a personal baseline.Alternatively or in addition such instance may be generated to determinea personal spike. At step 306, personal event data is communicated tocontext-based event detection system 132. As noted above, in someembodiments, a threshold may be applied to determine when (i.e. trigger)such communication. Receipt of the thresholds is not shown.

FIGS. 4A and 4B depict flowcharts for exemplary context-based eventdetection processes 400 and 410 consistent with the disclosedembodiments. In some aspects, context-based event detection system 132receives an instance of personal event data from client device 102 (step402). Such personal event data is associated with a user 110 and isprocessed and stored (step 404) to define and maintain a personalbaseline for the user 110. Such baseline data may be useful to compareto respective instances of personal event data to identify personalspikes, generally characterized and instances falling outside or beyondregular parameters of the personal data, which spikes may be indicativeof the occurrence of a personal event. The personal baseline may beconfigured using machine learning or other techniques to define a model,machine or other prediction component whereby a new instance of personalevent data may be processed to determine whether such instance is apersonal spike or otherwise within “normal” parameters of the personalbaseline. Tracking of personal event data may be performed by trackingone or more types of input data, for example, multiple types ofbiometric data (e.g. heart rate, sweat, etc.) Individual or combinedbaselines may be established for each input and thresholds (e.g. basedon X deviations from baseline) similarly established to identifypersonal spikes. The output of such model, machine or other predictioncomponent may have an associated confidence interval.

In some aspects, context-based event detection system 132 receives aninstance of personal event data from client device 102 (step 412). Theparticular instance of personal event data is analyzed at step 414 (e.g.processed by a model, machine or other prediction component of thepersonal baseline as described) to detect whether a personal spike hasoccurred. If a spike is not detected, processing stops via “No” branchfrom step 416. If a spike is detected, via “Yes” branch from step 416processing continues. At step 418, context-based event detection system132 may provide personal event information to a personal eventdetermination process such as at context-based event event determinationsystem 152.

Though context-based event detection system 132 is depicted as aseparate component of environment 100, features and functions ofcontext-based event detection system 132 may be provided by clientdevice 102 and such context-based event detection system 132 may beeliminated.

FIG. 5 depicts a flowchart for an exemplary personal event determinationprocess 500 consistent with the disclosed embodiments. In some aspects,context-based event determination system 152 maintains scenario modelingdata related to various personal event scenarios (step 502). As noted inthe description with reference to FIG. 1, such operations may includedefining and training a machine-learning model and/or other predictioncomponent(s). Feedback to such model may be provided from otherprocesses such as process 600 described below. Feedback may include dataconfirming or refuting the predicted scenario and may be used to refineand re-train the scenario data model and/or the baseline.

In some aspects, context-based event determination system 152 collectscontextual data 160 related to client (e.g. user 110). As noted,contextual data may be received, at various times, by context-basedevent determination system 152 from client device 102, other clientdevices (not shown), context-based event detection system 132, and otherthird party systems and entities as previously described. The contextualdata may be stored in database 156. Contextual data may be related invarious manners such as by time of occurrence, source (e.g. user, friendor family of user, co-worker, etc.), etc.

In one aspect, contextual data sources may be delineated and analyzedsuch as in a prioritized sequence. The following describes thedelineation of three types of data sources for consideration:

A. Personal sources: the user's social media (e.g. something the userposted);

B. Connected sources: friend's social media about the user (e.g.something a friend notices), and/or social media from other people inproximity (as noted previously)); and

C. Global sources: (related to the user) such as public media referencesto the user.

These sources may be analyzed in a priority sequence (A>B>C) for furtherconfirmation.

In addition to collecting contextual data from other devices or systems,context-based event determination system 152 may generate contextualdata (not shown). As previously described, personal event determinationsystem 152 may process contextual data for a user associated with one ormore personal spikes and generate candidate personal event scenarios.Such scenarios may be used as contextual data for the user or others(e.g. friends or family) identified by the scenarios. By way of example,assume processing relative to user A identifies a scenario whereby userA is associated to a personal event involving the child of user A (e.g.user A receives news that child of user A is having a baby). Processingpersonal spike and contextual data associated to the child of user A mayoutput a related personal event scenario (child of user A receives newsthat child of use A is having the baby). Using the output from theprocessing of the child of user's A personal spike and contextual datain relation to the processing of the user's respective data may assistto raise the confidence interval associated with the output for theuser.

At step 506, personal spike data for a client's personal event isreceived such as from context-based event detection system 132. At 508contextual data 160 for client (e.g. user 110) is analyzed such as togenerate a data set associated with the personal spike. In some aspects,time windowing and other relations may be used to select among thecontextual data available (further discussed below). At step 510, usingthe scenario data model (prediction component), the personal spike andcontextual data is evaluated to determine one or more candidate personalevent scenarios. Such scenarios may be associated with a likelihood ofaccuracy. A confidence interval may be established (step 512). Thoughsteps 510 and 512 are shown as separate steps, such may be combinedwhereby the confidence interval is established when or as the candidateis determined.

At step 514, the likelihood for each candidate is evaluated. If thelikelihood is not sufficient for a respective candidate, processing ofthe candidate may end via “No” branch from 514. If it is sufficient,processing for the scenario may continue via “Yes” branch. At step 516,one or more candidate scenarios meeting the likelihood determination instep 514 are provided to a financial product offering process such asmay be operated by financial offering system 172. Likelihood thresholdsmay vary by scenario. That is not all scenarios need meet or exceed thesame confidence interval threshold. For example, it may be lessimportant to be correct when concluding that one candidate scenario istrue versus another. Incorrectly concluding that a user is about to goon a trip is less risky or less important than incorrectly concludingthe user has recently lost a job.

Though not shown the output of the candidate and the confidence intervalmay be stored as contextual information for the client or another friendor family as identified in the scenario.

Time-windowing was previously discussed as a technique for selectingamong the contextual data to evaluate various candidate scenarios withinthe personal data model. In one aspect, personal event scenarios modeledare grouped to classes where each class represents like time windows inthe database 156. For example, a car crash may be defined as a class 1scenario, losing a job as a class 2 scenario and a new pregnancy as aclass 3 scenario. The classes are associated to like time windows suchas:

Class 1: only examines personal event data, contextual data and clientdata within a window of x hours about the personal spike;

Class 2: only examines personal event data, contextual data and clientdata within a window of x days; and

Class 3: only examines personal event data, contextual data and clientdata within a window of x weeks, etc.

Following a receipt of a personal spike, processing to evaluate whethera class 1 scenario occurred may be performed in response to theassociated time window. In one aspect, processing may be delayed, forexample, following the passage of x hours. If all events and contextanalyzed in the x hours of the time window do not identify a class 1scenario, processing may proceed to evaluate for a class 2 scenario or aclass 3 scenario, respectively. In one aspect, the receipt of thepersonal spike triggers the start of collection of the event-relateddata (e.g. particularly contextual data 160) for the applicable timewindows. In another aspect, event-related data may be continuouslycollected and the applicable time windows used to select from among thecollected data. It is understood that some types of event-related datamay be continuously collected and others collected in response to thepersonal spike.

FIG. 6 depicts a flowchart for an exemplary financial offering process600 consistent with the disclosed embodiments. In some aspects,financial offering system 172 maintains client financial information(step 602). In other aspects, a separate financial system (not shown)maintains such client financial information and provides access theretoto financial offering system 172. At step 604, financial offering system172 maintains financial product data for respective financial products(which as noted above includes services) available (offerable) toclients

In some aspects, financial offering system 172 maintains financialevents data associating respective financial products to particularpersonal event scenarios. In some embodiments, the association betweenevents and financial products may employ a predictive model such as byusing the modeling techniques described above. For example, initialtraining data may define the predictive model and further real worldobservable data, gathered over time, may be used to refine the scenariodata model. The real world and training data may comprise events.Personal event detection system 152 may output personal event scenariosfor users as described. Processing such as within financial offeringsystem 172 may observe whether such users spontaneously (i.e. withoutreceiving a personal event triggered offer as described herein) requirefinancial assistance in association with the events and which productsare sought by clients experiencing personal scenarios to define therelationships between events and products. Client financial datagenerated pre- and post-time of occurrence of the personalspike/personal event may be evaluated. Collection of client financialdata in association with providing the products may include informationto link or associate the client's desire/requirement to the personalevent. For example, among others, the client may indicate why thefinancial product is sought. The client may ask that certain assets beremoved from the client financial data, for example such as when a caris destroyed and a new loan is sought. For the description of theremaining steps of process 600 it is assumed that the financial eventdata and association to financial products is in place to supportprocess 600.

At step 606, a personal event scenario is received for a client (e.g.user 110). More than one event scenario may be received and similarlyprocessed as described. Using the financial event data, a determinationis made whether the event scenario indicates financial action isindicated. That is, whether one or more financial products areassociated to the personal event scenario. By way of example, a personalevent scenario that indicates the client was involved in a car accidentin which the client's car was damaged beyond repair may be associated toa car loan financial product. By way of another example, a personalevent scenario that indicates the client witnessed a car accident butsuffered no injury or damage to the client's vehicle may not beassociated to any financial product. One or more than one financialaction may be associated with a personal event scenario. Each scenariomay be associated with general or specific receptivity indicators. Apersonal score representing receptivity to financial product offeringsfor a particular client may be computed and provided, for example, to anadvisor. When a client experiences a personal event scenario,receptivity indicators associated with the scenario (e.g. by thefinancial event data) may then be associated to the client. One or morereceptivity indicators associated to a respective client may becombined, such as through averaging or taking the score representing theleast receptive or other techniques. Such a score and in addition or inthe alternative the fact that the particular client experienced aparticular personal event scenario may be available such as whendisplaying client information and/or client financial data. In oneaspect the score and or information about the scenario may betransmitted across a network to another computer system such as oneconfigured for use by financial advisors.

If no financial action is needed, via “No” branch to 610, otherhelp/information may be provided, if indicated. Thereafter, operationsend.

Examples of non-financial assistance that may be provided include:

-   -   providing individuals involved in a car accident with        information on driving lessons (which might be triggered by an        age threshold and the absence of having taken lessons, i.e.        under 18), or information on alternative routes/options (with        less traffic congestion), or information on public        transportation which might be triggered by an age threshold        (i.e. over 70))    -   providing individuals planning a wedding with information and        contacts for arranging prenuptial agreements (which might be        triggered by a specific income or asset threshold), or        information about marriage courses (which might be triggered by        specific cultural or religious beliefs).

If a financial product is associated such that a financial actionoffering a new product (or extending terms of existing financialproduct, etc.) is indicated then via “Yes” branch to step 612, in oneaspect, operations determine anticipated financial needs associated withthe personal event. Parameters to assist with such determination may bedefined in financial events data 178. Determination processing may alsoreview client financial data 180 or other data (not shown) whetherstored internally or externally to system 172. For example, insurancedata within client financial data 180 of user 110 may indicate that user110 has no collision coverage on car insurance for the vehicle involvedin the accident indicated in the personal event. Client financial data180 may show historic prices and or vehicles owned by user 110 such thatan estimate of a new car purchase price can be determined. Thedetermination processing may identify a class of automobile likelydesired by user 110 and search extemally (e.g. perform operations thatcommunicate with another computer system) for a range of such pricing.Such pricing may be useful in subsequent processing as described.

At step 614, a determination may be made whether client (e.g. user 110)may meet the financial needs such as without any assistance from anadditional financial product. Client financial data may be reviewed andcompared to the anticipated financial need determined at step 612. Forexample, if the client has sufficient liquid assets such as in a bankaccount or other liquid investments to cover the price of a car, a carloan may not be indicated for the particular user 110. Via “Yes” branchto 610, operations end.

If the client cannot meet such needs, via “No” branch to 616, thefinancial products can be analyzed to determine availability orsuitableness for the client and an offer made, if indicated. Clientfinancial data may be reviewed. For example, if a loan is an indicatedfinancial product, the client's credit rating, etc., may be evaluated todetermine an appropriate loan, loan amount, rate or other factor or notto extend a loan. If a client is not credit worthy, other forms offinancing such as those not provided by the financial offering entitymay be indicated. For example, system 172 may evaluate at connectedcircles (friend's/family) or other possible sources (governmentassistance, assistance from the public such as crowd funding,peer-to-peer lending, micro-financing, etc. Process 600 may beconfigured to offer such other assistance such as at step 610. It isunderstood that for at least some types of offerings, particularlyinformational offerings, a “means test” as described with referenced tosteps 612, 614 and/616 need not be performed. The offerings may beprovided (e.g. operations performed to transmit information etc. toother computer systems, client lists modified, etc.) without determiningthat a client qualifies. Such qualification may be determined later, forexample, if the client replies to the offering.

An offer of a financial product may be extended in accordance withclient preference information stored in client financial data 180 andoffer related data defined in financial products data 182. For example,an offer or invitation to contact the offering entity may be sent via anelectronic message to client device 102 or another device (not shown). Atelephone call or other contact (e.g. via mail delivery) may be made.For example, rules and or requirements about how to enroll a user for aparticular financial product may be defined in the financial productsdata 182. Processes may be employed accordingly and may be employed byseparate computer systems (not shown).

Offers herein may be an action offer for a particular product includingterms or may be informational, describing possible products to theclient to prime the client to contact the offering entity or to bereceptive to further contact by the offering entity. More than one offerfor the same or different products indicated for the personal event maybe extended to a client.

The timing of such offering may vary in accordance with the personalevent scenario, for example, so that the user is more likely to bereceptive to such an offer. As noted, receptivity indicators may beassociated to the personal event scenario and/or financial actionofferings. These receptivity indicators may be useful to determine whento or when not to communicate offerings. Time-periods after theexperiencing of the personal event scenario may be determined from thereceptivity indicators.

At step 618, the client accepts and/or replies to the offer or not. Ifnot accepted, processing may follow to step 610 and end, via “No” branchat step 618. If accepted, processing may following to step 620 via “Yes”branch at step 618.

At step 620, the financial product is provided. Routine financialproduct provision processes may be employed accordingly. Processing mayalso continue at step 610.

Feedback of information is provided to confirm model data (e.g. at 622)Feedback of information from various processing operations such as at612, 616 and/or 620 and/or from monitoring activities after suchoperations (e.g. via survey, etc. (not shown)) may be assistive toconfirm model data (e.g. at operations 500) as well as to steps 602and/604 of operations 600 and/or the personal event baseline. Thoughshown as an operation prior to the end of operations 600, the feedbackmay be given at other times and/or following earlier operations.Information related to the offering and/or the provision of thefinancial product and any related information may be fed back tocontext-based event detection system 132 and/or to context-based eventdetermination system 152 (feedback not shown). The client may indicatethat the personal event did in fact occur or not and/or may advise as tocorrective details. For example, such information may validate or notthe output and conclusions of such systems and operations described toassist with further respective machine learning within the predictioncomponents as described. The information related to the offering, itsacceptance or not and/or related to the providing of the financialproduct may be useful to define contextual data for the user 110, etc.It may also be useful to refine associations of the financial actions toscenarios and receptivity indicators.

The personal event scenario determined at step 608 may be associatedwith an action that is not an offering of a new financial product (orthe extension of new terms for an existing product, etc.). Thus afinancial needs assessment and a user's fit for the new product (e.g.credit worthiness, etc.) may not be required. In one aspect, the actionmay relate to an existing financial product. For example, the detectionof a particular scenario may be associated with an action which freezes(e.g. invokes the placement of a hold upon) certain accounts or productssuch as for a time-period. In some aspects, the freezing may be subjectto an override by the account holder/user. By way of example, thepersonal event scenario detected may be the user's break up of arelationship. The user may have indicated that break ups lead toregretful spending sprees. The action triggered by the detection of thepersonal event scenario may be a hold placed on certain accounts, creditcards, etc. such as for a certain time-period.

It is understood that personal event scenarios may be associated withmore than one action in relation to one or more financial products. Forexample, the determination that a user has purchased a new home mayinclude actions in relation to any one or more of a mortgage, mortgageinsurance, home insurance, change of address for accounts, etc.

Various embodiments have been described herein with reference to theaccompanying drawings. It will, however, be evident that variousmodifications and changes may be made thereto, and additionalembodiments may be implemented, without departing from the broader scopeof the disclosed embodiments as set forth in the claims that follow.

Further, other embodiments will be apparent to those skilled in the artfrom consideration of the specification and practice of one or moreembodiments of the present disclosure. It is intended, therefore, thatthis disclosure and the examples herein be considered as exemplary only,with a true scope and spirit of the disclosed embodiments beingindicated by the following listing of exemplary claims.

What is claimed is:
 1. A system comprising: a storage device; and atleast one processor coupled to the storage device, the storage devicestoring software instructions for controlling the at least one processorwhen executed by the at least one processor, the at least one processorbeing operative with the software instructions and being configured to:maintain scenario modeling data related to a plurality of personal eventscenarios; perform operations to communicate with one or more computersystems over a network to receive personal event data representing apersonal spike for a user of a client device, the personal spikecomprising an instance of personal event data that deviates from abaseline of personal event data determined for the user; performoperations to communicate with one or more computer systems over thenetwork to collect contextual data related to the personal event data;and, using the scenario modeling data, contextual data and the personalevent data identifying the at least one personal spike: determine andprovide likely personal event scenarios consistent with the contextualdata and the personal event data.
 2. The system of claim 1 wherein thepersonal spike deviates at least a threshold amount from the baseline ofpersonal event data.
 3. The system of claim 1 wherein the contextualdata comprises one or more of: emotion characterization data; personalspike time of occurrence data; user browsing history data; user calendardata; user messaging data comprising email, text, voice, and/or socialmedia data for communications sent or received by the user; userpositional data comprising location based services data,traffic/infrastructure data, utility service data comprising911/emergency services dispatch data, Internet of Things (IoT) data;proximity social trend/feed data comprising social media data originatedby friends/family or other person sharing a proximity relationship tothe user; associated transaction behaviour data; and general informationcomprising news, weather, sports, business and arts/entertainmentinformation.
 4. The system of claim 1, wherein the at least oneprocessor being further configured to select from among the contextualdata collected using at least one relationship.
 5. The system of claim 4wherein the relationship is a time relationship associated with a timeof occurrence for the personal spike.
 6. The system of claim 4 whereineach of the personal event scenarios are associated with a respectivetime window associated with a time of occurrence of the personal spikeand wherein the step of using for a particular personal event scenariois responsive to the time window to determine which contextual data toevaluate for the particular personal event scenario.
 7. The system ofclaim 6 wherein the personal event scenarios are grouped by like timewindows and evaluated in order beginning with the shortest time window.8. The system of claim 1, wherein the at least one processor beingfurther configured to, for each of the likely personal event scenarios,determine a likelihood that a respective likely personal event scenariois correctly predicted; and provide the likely personal event scenariosin association with the likelihood.
 9. The system of claim 1, whereinthe at least one processor being further configured to: performoperations to communicate with the one or more computer systems over thenetwork to receive feedback in respect of the occurrence of the likelypersonal event scenario; and use the feedback to maintain the scenariomodeling data.
 10. A computer-implemented method, comprising:maintaining, by at least one processor, scenario modeling data relatedto a plurality of personal event scenarios; performing, by the at leastone processor, operations to communicate with one or more computersystems over the network to receive personal event data representing apersonal spike for a user of a client device, the personal spikecomprising an instance of personal event data that deviates from abaseline of personal event data determined for the user; performing, bythe at least one processor, operations to communicate with one or morecomputer systems over the network to collect contextual data related tothe personal event data; and, using, by the at least one processor, thescenario modeling data, contextual data and the personal event dataidentifying the at least one personal spike to determine and providelikely personal event scenarios consistent with the contextual data andthe personal event data.
 11. The method of claim 10 wherein the personalspike deviates at least a threshold amount from the baseline of personalevent data.
 12. The method of claim 10 wherein the contextual datacomprises one or more of: emotion characterization data; personal spiketime of occurrence data; user browsing history data; user calendar data;user messaging data comprising email, text, voice, and/or social mediadata for communications sent or received by the user; user positionaldata comprising location based services data, traffic/infrastructuredata, utility service data comprising 911/emergency services dispatchdata, Internet of Things (IoT) data; proximity social trend/feed datacomprising social media data originated by friends/family or otherperson sharing a proximity relationship to the user; associatedtransaction behaviour data; and general information comprising news,weather, sports, business and arts/entertainment information.
 13. Themethod of claim 10 comprising selecting, by the at least one processor,from among the contextual data collected using a time relationshipassociated with a time of occurrence for the personal spike.
 14. Themethod of claim 13 wherein each of the personal event scenarios areassociated with a respective time window associated with a time ofoccurrence of the personal spike and wherein the step of using for aparticular personal event scenario is responsive to the time window todetermine which contextual data to evaluate for the particular personalevent scenario.
 15. The method of claim 14 wherein the personal eventscenarios are grouped by like time windows and evaluated in orderbeginning with the shortest time window.
 16. The method of claim 10comprising, for each of the likely personal event scenarios,determining, by the at least one processor, a likelihood that arespective likely personal event scenario is correctly predicted; andproviding the likely personal event scenarios in association with thelikelihood.
 17. The method of claim 10 comprising performing, by the atleast one processor, operations to communicate with one or more computersystems over the network to collect contextual data related to thepersonal event data.
 18. The method of claim 10, comprising: performingoperations, by the at least one processor, to communicate with the oneor more computer systems over the network to receive feedback in respectof the occurrence of the likely personal event scenario; and using, bythe at least one processor, the feedback to maintain the scenariomodeling data.
 19. A system comprising: a storage device; and at leastone processor coupled to the storage device, the storage device storingsoftware instructions for controlling the at least one processor whenexecuted by the at least one processor, the at least one processor beingoperative with the software instructions and being configured to:perform operations to communicate with one or more first devices over anetwork to receive instances of personal event data for a user of aclient device; perform operations to communicate with one or more seconddevices over a network to receive contextual data for the user;establish and maintain a baseline of personal event data for the userusing the contextual data and instances of personal event data; andidentify a personal spike experienced from one or more instances ofpersonal event data that deviate from the baseline.
 20. The system ofclaim 19 wherein the at least one processor is further configured toperform operations to communicate to the personal spike to a personalevent scenario determination computer system.